1. Field of the Invention
The present invention generally relates to graphics systems, and more particularly to a novel system and method for managing graphics data in a single logical screen (SLS) graphics system.
2. Discussion of the Related Art
Computer graphics displays that have very large sizes and high resolutions are useful in a variety of applications. For example, such displays can be used to create immersive environments in which viewers are surrounded by the display. Such displays are also useful when large amounts of data must be viewable on one large screen, such as in stock market applications, large process control applications and the like. Frequently, in order to provide such a large display with adequately high resolution, a composite screen must be constructed using numerous separate physical display devices such as graphics hardware and CRT-type monitors. If the composite screen is to be used interactively, then suitable control mechanisms are also provided so that objects presented on the composite screen may be moved about and otherwise manipulated freely without regard to the fact that different portions of the objects are actually displayed on different physical display devices. In other words, the different physical display devices comprising the composite screen are controlled in concert so that they present the illusion of one large logical screen to the viewer. This kind of functionality has become known as “single logical screen” functionality, or simply “SLS.” One solution for providing single logical screen functionality in an X-Window System environment is taught by Jeffrey J. Walls, Ian A. Elliott and John Marks in U.S. Pat. No. 6,088,005, issued Jul. 11, 2000, titled “A Design and Method for a Large, Physical Workspace” (hereinafter “Walls, et al.”), which patent is hereby entirely incorporated by reference.
By way of background, the X-Window System is a standard for the implementation of network-based UNIX-Window systems. The X-Window System provides users and developers with the functionality for creating and managing a window environment in a network-based computer system.
The X-Window System Server (X-Server) is a multi-user device that controls the shared access to X-Window resources through a standard interface called Xlib. Each executing X-Server manages a single graphics display comprising a keyboard, a pointing device, such as a mouse, and one or more graphics hardware devices, each having one or more associated physical monitors. Physical monitors can differ in size, while graphics hardware devices differ in depth, and visual classes. The visual classes provide such information as: whether the graphics hardware supports color or grayscale, whether the set of displayable colors or shades of gray is fixed in hardware or can be changed, and if the monitor supports color, whether the intensities of red, green, blue primary colors are determined from a single lookup table or from individual tables, and the depth of the graphics hardware device which is the number of bits needed to represent a color.
The X-Server operates in two (2) multi-head configurations which are configurations comprising multiple physical monitors. The multi-head configurations are multi-seat and multi-screen. A multi-seat configuration comprises a graphics display dedicated to each user. Therefore, each user has a keyboard, mouse, one physical monitor, plus an X-Server to manage the graphics display. The graphics displays are completely independent of each other. A multi-screen configuration comprises a single graphics display connected to multiple physical monitors. Therefore, a user has a keyboard, mouse, multiple physical monitors, and one X-Server. A cursor on one physical monitor can be moved between the physical monitors. The X-Server, however, in some applications has been limited in that it cannot create, move, nor span windows across the physical monitors. In these applications, window borders were restricted to the size and location of the physical monitor on which they were created.
This problem was most prevalent in two-dimensional graphic systems requiring the display of large amounts of data that cannot be completely displayed on one physical monitor. Examples of such large data systems include: real estate, financial (such as the stock market), control room, large engineering processes, military mapping, and telecommunications. Each of these systems requires the output of large amounts of data which can easily exceed the display capacity of a single physical monitor. A user can only view these large data sets by panning and zooming. Multiple screens are needed to shuffle between the layers of individual windows.
A user of a multiple physical monitor system would greatly benefit if the X-Server managed the multiple physical monitors as a single logical screen in which windows, as well as the pointer, can cross physical monitor boundaries. Therefore, the user could manipulate the single logical screen just as if it were a single physical monitor. The user would have full screen capabilities across each of the individual physical monitors, thereby providing the full presentation of large amounts of data in a useful format.
The invention of Walls et al. solved the problem of managing multiple physical monitors as a single logical screen, SLS, by adding an SLS layer to the X-Server protocol, thereby creating an SLS X-Server. An SLS X-Server is generated when a server is initialized. Generally, at initialization, a user establishes the configuration of the SLS by defining the physical arrangement of the multiple physical monitors. The SLS X-Server then allocates SLS data structures and initializes the multiple physical monitors that comprise the SLS. One feature of Walls et al. was that the SLS layer provides a mechanism for translating a user's SLS window operation request to multiple physical monitors. Thus, a user possesses fill screen capabilities in an SLS environment, such as moving, spanning, and resizing windows, as well as moving the pointer, across physical monitor boundaries.
One issue in SLS systems relates to the implementation and handling of context data. As is known, unique sets of context data are generally associated with different processes or different windows. Although there may be multiple contexts for a given window, a single graphics context is limited to a single window. As is further known, the “active” context data for a given window is loaded into the graphics hardware, and includes information such as lighting information, transform matrices, color information, and other graphics state information. Once the context data is loaded into the graphics hardware, the hardware uses this data for processing primitives, before rendering the primitives to the display.
In situations where multiple context data sets are involved, and the context for a display or window changes, the current context data is saved from the graphics hardware to memory. Thereafter, the “new” context data is written from memory into the graphics hardware.